Skip to content

Update tutorial-sync-gateway-manage.adoc #21

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 5 commits into
base: release/2.8
Choose a base branch
from

Conversation

iamfortune
Copy link

Added authorization headers and a note on auth headers for requests.

Added authorization headers and a note on auth headers for requests.
@osfameron osfameron requested review from tech-comm-team-couchbase and removed request for tech-comm-team-couchbase July 15, 2025 13:19
Copy link

@torcolvin torcolvin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think for k8s, we should drop running sgcollect from the command line at all, in this section:

To collect logs on a specific pod, run `sgcollect_info` using the `kubectl` https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#exec[exec command^].
The following command runs `sgcollect_info` on the specified pod and outputs the results to an *out.zip* file.
[source,console]
----
$ kubectl exec <pod_id> -- /opt/couchbase-sync-gateway/tools/sgcollect_info /tmp/out.zip

This should be replaced with

kubectl exec "$pod" -- curl -X POST https://localhost:4985/_sgcollect_info -H 'Accept: application/json' -H 'Authorization: Basic c3luY19nYXRld2F5OnBhc3N3b3Jk' -d `{"output_dir": "/home/sync_gateway/logs"}`

so it is running /_sgcollect_info.

This is particularly critical given that the arguments for sgcollect are changing in 3.3 in a backward incompatbile way (https://jira.issues.couchbase.com/browse/DOC-11719) and the REST endpoint will always work for k8s.

The k8s convenience script should be updated. This requires jq on the local system, but I think that's not uncommon and there isn't another cross platform way to grab output. I see we suggest jq in some documents, so I think this is fine. In practice, I think that operator users should just use upload: true and then won't need to run this "convenience" script.

#!/bin/bash

for pod in $(kubectl get pods -o=name | grep sync-gateway | sed "s/^.\{4\}//"); do
    echo "Running /_sgcollect_info on $pod"
    REMOTE_OUTFOLDER="/home/sync_gateway/logs/sgcollects_$pod"
    kubectl exec "$pod" -- mkdir -p "$REMOTE_OUTFOLDER"
    kubectl exec "$pod" -- curl -X POST https://localhost:4985/_sgcollect_info -H 'Accept: application/json' -H 'Authorization: Basic c3luY19nYXRld2F5OnBhc3N3b3Jk' -d "{\"output_dir\": \"$REMOTE_OUTFOLDER\"}"
    echo "Waiting for /_sgcollect_info to finish on $pod"
    # wait for 60 minutes of output
    for attempt in {1..120}; do
        RESPONSE=$(curl -u Administrator:password -X GET kubectl exec "$pod" -- curl -X GET https://localhost:4985/_sgcollect_info -H 'Content-Type: application/json' -H 'Authorization: Basic c3luY19nYXRld2F5OnBhc3N3b3Jk')
        STATUS=$(echo "$RESPONSE" | jq -r '.status')
        echo "Current status is $STATUS"
        if [[ "$STATUS" != "running" ]]; then
            break
        else
            echo "Attempt $attempt: status is '$STATUS' — waiting..."
            INTERVAL=30
            sleep "$INTERVAL"
        fi
    done
    echo "copying $pod:$REMOTE_OUTFOLDER to current folder"
    kubectl cp "$pod":"$REMOTE_OUTFOLDER" .
done

Separately:

$ curl -X GET \
  http://localhost:4985/_sgcollect_info \
  -H 'Accept: application/json' \
  -H 'Content-Type: application/json'

should be updated with https and an authorization header.

-d '{
"output_dir": "/home/sync_gateway/logs",
"upload": false
}’
----

NOTE: When you set `admin_interface_authentication` to `true` in your Sync Gateway configuration, include authentication headers in your requests.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would drop this line, I'd always expect that especially k8s uses are using admin authentication. If they aren't using authentication (this should never be the case!) then setting a an authorization header is unnecessary.

Especially because this is k8s documentation and they are more likely to have the correct certifcation information, I would have the SG urls always use https, so a find and replace on http://localhost:4985 to https://localhost:4985 would be appropriate.

I even think using tls for non Sync Gateway documentation is correct because folks should always configure Sync Gateway with TLS, and you have to really opt out to do this.

admin_interface_authentication is true by default.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I made some changes to the file.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants